1. Field of the Invention
The present invention relates to authentication and security in networked computer systems. More particularly, the present invention relates to a method and apparatus for managing a set of trusted certificates for authenticating communications to and from entities belonging to an enterprise.
2. Related Art
The advent of computer networks, such as the Internet, and the rise of the World Wide Web have led to an explosion in the development of applications, such as web browsers and web servers, that facilitate rapid dissemination of information. Using the World Wide Web, it is presently possible to instantaneously access information on the weather in Africa or stock prices in Tokyo with only a few clicks of a computer mouse.
As the Internet continues to evolve, it no longer merely functions as a mechanism for dissemination of information; it is also becoming an infrastructure that supports electronic commerce. The Internet is now commonly used to sell items such as books, software, compact discs, and even investment securities. One major challenge in facilitating such transactions is that parties to a transaction require confidence that communications received from other parties originate from parties that can be trusted.
The public key infrastructure (PKI) has been developed to provide some measure of confidence that communications originate from authenticated parties. The public key infrastructure uses mathematically related private key/public key pairs to authenticate communications across a network. In a typical mode of operation, an entity sending a communication signs it with its private key. This enables another entity receiving the communication to use the corresponding public key to verify that the communication has been signed with the private key. Note that private key/public key pairs are designed in such a way that a holder of a public key cannot easily construct the private key from the public key. Hence, the public key can be freely distributed without compromising the private key. The public key is typically propagated to other entities on the network through some verifiable mechanism, such as hand delivery, or through digital signature techniques which are described in the detailed description below.
The public key infrastructure presently relies on certificate authorities (CAs) to establish trust among entities that communicate with each other through the public key infrastructure. A CA typically issues a "certificate" to an entity on the network after first verifying the identity of entity. This certificate typically contains an identifier for the entity along with a public key belonging to the entity. This public key can be used to authenticate that a communication is signed with the private key of the entity, and has hence originated from the entity.
In order to provide some degree of confidence that a particular certificate is valid, the certificate is signed with the private key of the CA so that other entities can use the public key of the CA to verify that the certificate has been signed by the CA. The fact that the certificate has been signed by the CA indicates that the CA has somehow verified that the certificate belongs to a trusted party. The CA verifies this fact by receiving the public key from the party through a trusted communication channel, and optionally by asking additional questions of the party, or by receiving additional indicators that the party can be trusted.
Presently, one of the significant problems with the public key infrastructure is the task of initially establishing trust with various CAs. Web browsers, such as Netscape Navigator produced by Netscape Communications of Mountain View, Calif., presently include a list of trusted certificates from various certificate authorities. However, such lists may include certificates for CAs that are not acceptable to the enterprise because the enterprise may not have confidence in the procedures a particular CA uses to authenticate entities.
One solution to this problem is to make every user in an enterprise independently verify each CA the user wants to use. This verification may involve inquiring about the procedures used by a CA in issuing certificates as well as ensuring that the certificate for the CA actually originated from the CA. This solution is inefficient because it requires a large number of independent verifications. Furthermore, it is unreliable because users may make mistakes in verifying CAs.
Another solution is to use a technique known as "cross certification" in which a root CA verifies a group of other CAs and then signs their certificates. When a user determines that a certificate has been signed by the root CA, the user knows that the corresponding certificate authority has been verified by the root CA.
However, the root CA may belong to another organization outside of the enterprise. For example, VeriSign, Inc. of Mountain View, Calif. presently provides a root CA that is extensively used by other organizations. Unfortunately, the policies that a particular root CA uses in cross-certifying other CAs may not be acceptable to the enterprise.
What is needed is a mechanism that establishes and maintains a list of certificates for trusted CAs for users within an enterprise.